Documenting:

FAILED test_app/tests/resource_registry/models/test_resource_field.py::test_resource_field_prefetch_related - AttributeError: 'NoneType' object has no attribute 'name'
FAILED test_app/tests/rbac/remote/test_service_api.py::test_list_role_user_assignments - AssertionError: assert None == 'd81556af-c82e-4659-bde4-b0905f1a696b'
 +  where 'd81556af-c82e-4659-bde4-b0905f1a696b' = str(UUID('d81556af-c82e-4659-bde4-b0905f1a696b'))
 +    where UUID('d81556af-c82e-4659-bde4-b0905f1a696b') = <Resource: Resource object (974)>.ansible_id
 +      where <Resource: Resource object (974)> = <User: rando>.resource
FAILED test_app/tests/resource_registry/test_resources_api_rest_client.py::test_sync_org_assignment - AssertionError: assert 'f7f63489-91a5-4a9a-8eaa-ba7e409e1375' == None
 +  where 'f7f63489-91a5-4a9a-8eaa-ba7e409e1375' = str(UUID('f7f63489-91a5-4a9a-8eaa-ba7e409e1375'))
 +    where UUID('f7f63489-91a5-4a9a-8eaa-ba7e409e1375') = <Resource: Resource object (1509)>.ansible_id
 +      where <Resource: Resource object (1509)> = <User: _system>.resource
 +        where <User: _system> = RoleUserAssignment(pk=122).created_by
FAILED test_app/tests/resource_registry/test_resources_api.py::test_resource_summary_fields - AssertionError: assert 'resource' in {'modified_by': {'id': 878, 'username': '_system', 'first_name': '', 'last_name': ''}, 'created_by': {'id': 878, 'username': '_system', 'first_name': '', 'last_name': ''}}
FAILED test_app/tests/resource_registry/test_resources_api_rest_client.py::test_sync_obj_assignment - AssertionError: assert '1dc0fc62-4480-4198-9d7b-f9f5acee18c9' == None
 +  where '1dc0fc62-4480-4198-9d7b-f9f5acee18c9' = str(UUID('1dc0fc62-4480-4198-9d7b-f9f5acee18c9'))
 +    where UUID('1dc0fc62-4480-4198-9d7b-f9f5acee18c9') = <Resource: Resource object (1515)>.ansible_id
 +      where <Resource: Resource object (1515)> = <User: _system>.resource
 +        where <User: _system> = RoleUserAssignment(pk=123).created_by
FAILED test_app/tests/resource_registry/test_resources_api_rest_client.py::test_list_user_assignments - AssertionError: User assignment not found in list results
assert False
FAILED test_app/tests/resource_registry/test_resources_api_rest_client.py::test_list_team_assignments - AssertionError: Team assignment not found in list results
assert False
FAILED test_app/tests/rbac/remote/test_service_api.py::TestCreatedByAnsibleIdAllowNull::test_list_assignments_shows_created_by_when_present - AssertionError: assert None == 'de23093f-5d72-4de3-bced-660c8b0b1817'
 +  where 'de23093f-5d72-4de3-bced-660c8b0b1817' = str(UUID('de23093f-5d72-4de3-bced-660c8b0b1817'))
 +    where UUID('de23093f-5d72-4de3-bced-660c8b0b1817') = <Resource: Resource object (1105)>.ansible_id
 +      where <Resource: Resource object (1105)> = <User: assignment-creator>.resource
FAILED test_app/tests/rbac/remote/test_service_api.py::TestCreatedByAnsibleIdAllowNull::test_list_assignments_shows_null_created_by_when_null - assert None is not None
===== 9 failed, 2619 passed, 13 xfailed, 62 warnings in 559.17s (0:09:19) ======

Link #213

@ttuffin asking for your advisement on SonarCloud coverage data here. This reports that the new method isn't covered. This is somewhat obvious, because it is added for compatibility, and whatever the existing config is doing seems to only get coverage from one run. But clearly different runs in the matrix will cover different lines in code - otherwise why would we have a matrix?!

This is where a coverage requirement becomes very murky, as it gets highly highly configuration dependent. Do you want coverage to be gathered from all runs and combined? We have a clear preference, which is that we only "care" about Django 5, as the compatibility stuff is temporary, but cannot be avoided. Getting coverage for version-specific stuff is extra work and doesn't necessarily provide any value.

Tests I added meaningfully covered the non-trivial code related to processing of multiple querysets passed in. This seems pretty solid now.

@ttuffin asking for your advisement on SonarCloud coverage data here. This reports that the new method isn't covered. This is somewhat obvious, because it is added for compatibility, and whatever the existing config is doing seems to only get coverage from one run. But clearly different runs in the matrix will cover different lines in code - otherwise why would we have a matrix?!

This is where a coverage requirement becomes very murky, as it gets highly highly configuration dependent. Do you want coverage to be gathered from all runs and combined? We have a clear preference, which is that we only "care" about Django 5, as the compatibility stuff is temporary, but cannot be avoided. Getting coverage for version-specific stuff is extra work and doesn't necessarily provide any value.

@AlanCoding one potential solution could be to update the CI to generate coverage reports for each run, aggregate them and then send that aggregated report to SonarCloud. I am not sure what the long-term plan is for supporting Django 4 in dab, but I imagine we may still need add potential bug/CVE fixes in the future? In which case having coverage for Django 4 related code would be advantageous. Aggregated coverage reports is not something we covered in the initial proposal - perhaps it would be good to add some guidance around that.

All that said, I am happy to leave something like this to the discretion of the PDT's since you know your codebase best. In this particular case, SonarCloud appears to be getting caught up on code that you consider to be temporary for backwards compatibility purposes only, in which case I don't see a problem in excluding it with # NOSONAR.

HTH. If you think we should have better guidance about this from the SIG I'd be happy to raise it for discussion.

I am not sure what the long-term plan is for supporting Django 4 in dab, but I imagine we may still need add potential bug/CVE fixes in the future?

No it will not. We only need this temporarily in a mid-release sense. We need Django 4 support in this branch, only as a matter of branch management. It is a big undertaking to get users of DAB to upgrade, and may take a month or more.

I'll try to add NOSONAR

DVCS PR Check Results:

PR appears valid (JIRA key(s) found)

Quality Gate failed

Failed conditions
4 New issues
3 Security Hotspots
66.7% Coverage on New Code (required ≥ 80%)
E Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE